wafer.space Community - 💻-digital

Having an inverter at the output of a logic cell (buffering the internal node) is almost a given, right? So any custom gates in any static logic family I have to draw I should expect to use an inverter as an output buffer after the actual gate itself, right?

Sometimes you'll find _0 variants of gates where it's directly the internal output but yeah that's rate and not that useful for general P&R where you'd almost always have an inverter at the output ... except if the cell in question is an inverter or a delay cell .

1

namibj

Having an inverter at the output of a logic cell (buffering the internal node) is almost a given, right? So any custom gates in any static logic family I have to draw I should expect to use an inverter as an output buffer after the actual gate itself, right?

No. CMOS standard cells have NAND2 and AOI amd OAI cells that don't have inverter at the end and these cells will be used quite a lot in the synthesized netlist.

I just noticed the SRAM behavioral model has timing constraints (55.6 ns, ~18MHz). Do we know if this is a real limit of the SRAM, or just a quirk of the fab's sram model?

BreakingTaps

I just noticed the SRAM behavioral model has timing constraints (55.6 ns, ~18MHz). Do we know if this is a real limit of the SRAM, or just a quirk of the fab's sram model?

That seems close to the 1.8V figures on https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/SRAM/gf180mcu_fd_ip_sram/cells/gf180mcu_fd_ip_sram__sram512x8m8wm1/gf180mcu_fd_ip_sram__sram512x8m8wm1.html

8:24 p.m.

So I assume you can safely ignore at 5V or 3v3

aha good catch! Didnt realize the docs had those tables for the sram

8:39 p.m.

thanks!

Does anyone have t_FO4 on hand by chance?

@RebelMike @Leo Moser (mole99) Overdue update to my SCL: non-inverting latches. So you can use those now and drop any inverters you had to place in your design. Always remember to gate-level simulate, there should be no more missing cell models now.

2

Tholin

@RebelMike @Leo Moser (mole99) Overdue update to my SCL: non-inverting latches. So you can use those now and drop any inverters you had to place in your design. Always remember to gate-level simulate, there should be no more missing cell models now.

Awesome, thank you!

Tholin

@RebelMike @Leo Moser (mole99) Overdue update to my SCL: non-inverting latches. So you can use those now and drop any inverters you had to place in your design. Always remember to gate-level simulate, there should be no more missing cell models now.

Opened an open_pdks PR to update the hash: https://github.com/RTimothyEdwards/open_pdks/pull/525

Hello everyone I am trying to tapeout bunnie's Andrew Huang BIO Core https://www.crowdsupply.com/baochip/dabao/updates/bio-the-bao-i-o-co-processor in ws 2 run It has 2 core in a half height slot, I started with 2Kb sram each core ( 4Kb total ie 8 macros of (5128 ) ) but that arrangement is producing a lot of routing congestion I =have tried to stagger the columns vertically so they don't overlap in Y: Column 1 (core 0): X = 442, Y = 500, 1020, 1540, 2060 (bottom half) Column 2 (core 1): X = 1060, Y = 2600, 3120, 3640, 4160 (top half) But that is giving bad timing paths and congestion. Only Thing I can think of currently is to move 1Kb sram each core and use ( 8 macros of (2568)) this is my first time working in backend and SRAM so I would like to know is there possibility to actually fit 4Kb in the slot ? Sorry if the question is dumb or confusing . (edited)

BIO - The Bao I/O Co-Processor

BIO is the I/O co-processor in the Baochip-1x. In this update, I’ll talk about the origins of the BIO, starting by working through a detailed study of the Raspberry Pi PIO as a reference before diving into the architecture of the BIO.

1

BreakingTaps started a thread. 2026-06-17 4:32 p.m.

Here we go again!

7:26 p.m.

A bit of a problem with the 3.3V SCL: the antenna rules are even stricter for 3.3V!

huh interesting, my design is using your 3v3 library and I don't think it ran into any non-user-error antenna violations (I had a few originally because it was trying to cram logic between two closely spaced macros and then no room for diode placement). will double check when I get home, maybe it did and I didn't notice! (edited)

4:08 p.m.

Where do I report this?

4:08 p.m.

Its a major issue because the only workaround for it I’ve found so far is it to crank the area of the macro up to way above what is actually necessary (edited)

4:09 p.m.

Which is currently having the result that using my SCL yields a decrease in density

4:09 p.m.

Just by having to insert lots of blank space to stop this error from happening

@Tholin You're likely hitting this bug in OpenROAD: https://github.com/The-OpenROAD-Project/OpenROAD/issues/10273

Underflow error after antenna repair · Issue #10273 · The-OpenROA...

Describe the bug I'm getting a [ERROR GRT-0183] Net 22574: heap underflow during 3D maze routing. After antenna repair Expected Behavior No error. Environment 26Q2-555-gd71446d6e9 OpenROAD 26Q2...

4:15 p.m.

A workaround in LibreLane is to set CTS_APPLY_NDR: "none". It disables non-default rules for CTS.

Deepak

Hello everyone I am trying to tapeout bunnie's Andrew Huang BIO Core https://www.crowdsupply.com/baochip/dabao/updates/bio-the-bao-i-o-co-processor in ws 2 run It has 2 core in a half height slot, I started with 2Kb sram each core ( 4Kb total ie 8 macros of (5128 ) ) but that arrangement is producing a lot of routing congestion I =have tried to stagger the columns vertically so they don't overlap in Y: Column 1 (core 0): X = 442, Y = 500, 1020, 1540, 2060 (bottom half) Column 2 (core 1): X = 1060, Y = 2600, 3120, 3640, 4160 (top half) But that is giving bad timing paths and congestion. Only Thing I can think of currently is to move 1Kb sram each core and use ( 8 macros of (2568)) this is my first time working in backend and SRAM so I would like to know is there possibility to actually fit 4Kb in the slot ? Sorry if the question is dumb or confusing . (edited)

So I tried to figure a few thing out and it looks like repair_design is inserting ~12K buffers on clock nets before CTS ie +28% area explosion in Stage 31 (OpenROAD.RepairDesignPostGPL) inserts 12K buffers causing a +28.5% area jump. I then verifed in the openroad with the ODB , that shows only two nets with fanout above 50: clk_PAD2CORE (2,320 loads) and core_clk (980 loads) both are clock nets. The repair is happening entirely on clock nets that CTS then rebuilds anyway. Zero data path violations exist . What is the correct LibreLane config variable to prevent repair_design from touching clock nets before CTS runs? Also I noticed this warning [01:21:22] WARNING [GRT-0281] Net clk_PAD2CORE has a large fanout of 2320 terminals. (edited)

Deepak

So I tried to figure a few thing out and it looks like repair_design is inserting ~12K buffers on clock nets before CTS ie +28% area explosion in Stage 31 (OpenROAD.RepairDesignPostGPL) inserts 12K buffers causing a +28.5% area jump. I then verifed in the openroad with the ODB , that shows only two nets with fanout above 50: clk_PAD2CORE (2,320 loads) and core_clk (980 loads) both are clock nets. The repair is happening entirely on clock nets that CTS then rebuilds anyway. Zero data path violations exist . What is the correct LibreLane config variable to prevent repair_design from touching clock nets before CTS runs? Also I noticed this warning [01:21:22] WARNING [GRT-0281] Net clk_PAD2CORE has a large fanout of 2320 terminals. (edited)

Have you updated your project template and cloned the latest PDK? There was an issue in the OCD I/O cells that lead to CTS being skipped.

Leo Moser (mole99)

Have you updated your project template and cloned the latest PDK? There was an issue in the OCD I/O cells that lead to CTS being skipped.

hello Yes i am on version 1.5.4 of template and i did run clone-pdk so its up to date. Actually i am using a ICG Cell in my design so the clk_PAD2Core is input to that and core_clk is out put . So I suspect that .

It's possible that adding them to CLOCK_NET in the config would help. I have:

CLOCK_NET:
- i_chip_core.real_clk_gf180mcu_as_sc_mcu7t3v3__mux2_2_Y/Y
- clk5x_pad/Y

RebelMike

It's possible that adding them to CLOCK_NET in the config would help. I have:

CLOCK_NET:
- i_chip_core.real_clk_gf180mcu_as_sc_mcu7t3v3__mux2_2_Y/Y
- clk5x_pad/Y

Hello thank you , the sdc should add these clock nets as create clock right ? or clock group (edited)

So the congestion seems to be only get blobbed in a small section of the chip rest is just empty and tht is creating overflow in that local congestion And that ends up begin overflow in the GRT ( or that what i understood atleast) Is there a way to spread it I have tried with different logic density already form 30 to 50 And sorry fro continues spam here i am bit newbie in Pnr .

Deepak

So the congestion seems to be only get blobbed in a small section of the chip rest is just empty and tht is creating overflow in that local congestion And that ends up begin overflow in the GRT ( or that what i understood atleast) Is there a way to spread it I have tried with different logic density already form 30 to 50 And sorry fro continues spam here i am bit newbie in Pnr .

The variable you are searching for is PL_TARGET_DENSITY_PCT. Note that a lower value means a higher spread. What kind of message do you get during GRT? Normally, you can always continue at least to DRT if GRT_ALLOW_CONGESTION: true.

Leo Moser (mole99)

The variable you are searching for is PL_TARGET_DENSITY_PCT. Note that a lower value means a higher spread. What kind of message do you get during GRT? Normally, you can always continue at least to DRT if GRT_ALLOW_CONGESTION: true.

Yes I have iterated PL_TARGET_DENSITY_PCT from 30 to 50 but the results were creating same number of overflows ie is around 18 K The flow does go to the Detailed routing as i have kept GRT_ALLOW_CONGESTION: true but DRT starts with 90K violations and then just keeps on iterating it did went down to 79K but that took 12h . Then my system killed the process but I think 12h was too much anyway? Or is that normal I search on internet and found that maybe adding PAD_CELL might help what is you take on that ? (edited)

Deepak

Yes I have iterated PL_TARGET_DENSITY_PCT from 30 to 50 but the results were creating same number of overflows ie is around 18 K The flow does go to the Detailed routing as i have kept GRT_ALLOW_CONGESTION: true but DRT starts with 90K violations and then just keeps on iterating it did went down to 79K but that took 12h . Then my system killed the process but I think 12h was too much anyway? Or is that normal I search on internet and found that maybe adding PAD_CELL might help what is you take on that ? (edited)

You need to lower the value to spread the cells. For example. try PL_TARGET_DENSITY_PCT: 20.

Leo Moser (mole99)

You need to lower the value to spread the cells. For example. try PL_TARGET_DENSITY_PCT: 20.

my design utilisation was 27 % so i thought i should keep above that if that's not the case i will try 20 now Thank You much

Deepak

my design utilisation was 27 % so i thought i should keep above that if that's not the case i will try 20 now Thank You much

Increasing the target density means a higher routing congestion. Good luck!

1

Leo Moser (mole99)

Increasing the target density means a higher routing congestion. Good luck!

this worked thank you very much

Deepak

this worked thank you very much

That's great to hear!

Is there a better open-source tool than yosys/abc for retiming?

3:17 p.m.

I don't really understand it i guess, it feels like it doesn't work

Olle

Is there a better open-source tool than yosys/abc for retiming?

what problem are you encountering?

From a software perspective, I guess I assume retiming to be more powerful than it is. I was under the impression that this should distribute the implementation (booth or whatever) over multiple cycles (i.e, balance the gates):

module IntegerMultiply(
  input         clock,
  input  [31:0] inA,
                inB,
  output [31:0] out
);

  reg [31:0] prod_pipe_r0;
  reg [31:0] prod_pipe_r1;
  reg [31:0] prod_pipe_r2;
  reg [31:0] prod_pipe;
  always @(posedge clock) begin
    prod_pipe_r0 <= (inA * inB);
    prod_pipe_r1 <= prod_pipe_r0;
    prod_pipe_r2 <= prod_pipe_r1;
    prod_pipe <= prod_pipe_r2;
  end
  assign out = prod_pipe;
endmodule

This is for an ASIC, using abc (not abc9) (edited)

Is retiming even enabled by default in the flow ?

I'm fairly sure retiming doesn't happen in the Librelane flow. Though interestingly retime is passed to ABC. I found this in a search: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/discussions/1782#discussioncomment-8264228 which suggests ABC only sees combinational logic. Which is possibly why you always see the error ABC: Error: The network is combinational. But clearly yosys can do retiming because it works on some FPGA flows - I guess if you wanted to investigate further you could compare the synth scripts for an FPGA and librelane

Interesting. I'm pretty sure I got it to work at least once. I have done so many experiments so I feel a bit lost, but iirc retiming worked well until i added input/output delays in my .sbc file. I'll do some more experiments tomorrow and update. (edited)

RebelMike

I'm fairly sure retiming doesn't happen in the Librelane flow. Though interestingly retime is passed to ABC. I found this in a search: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/discussions/1782#discussioncomment-8264228 which suggests ABC only sees combinational logic. Which is possibly why you always see the error ABC: Error: The network is combinational. But clearly yosys can do retiming because it works on some FPGA flows - I guess if you wanted to investigate further you could compare the synth scripts for an FPGA and librelane

(it doesn't work very well though, because it retimes after mapping LUTs, not during mapping LUTs)